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1.0 ISTBODOCTIOS 


1.1 BACKGROUND 


The Shuttle Program Information Management System 
(SPIMS) project was established at the Lyndon B‘. Johnson 
Space Center (JSC) to automate the storage and retrieval of 
massive volumes of data relating to several management 
.responsibilities assigned by the Space Shuttle Program 
Office (SSPO) . 

Applications developed for SPIMS in support of these 
management responsibilities were identified and allocated to 
JSC by SSPO (see the Program Information and Coordination 

Beview Service fPlCBS ) Management Plan ) . These applications 

currently are; 

• Document Index System (DIS) 

• Shuttle Beguirements Traceability (SET) 

• Problem Data Systems (PDS) 

• Stowage List and Hardware Tracking System (SIAHTS) 

• Master Measurements Data Base (MMDB) 

• Shuttle Automated Hass Properties System 

• Resources, Scheduling and Procurement Integration 
(RSPI) 

The SPIMS Functional Design is the result of two 
studies, a feasibility study performed during the second 
quarter of fiscal year 1974 and a requirements study 
performed during the third and fourth quarters of 1974. The 
results of the feasibility study can be found in the 
Implementation Feasibility Study for S p ace Shuttle Program 



Wanagenent System Applxcation Final Report . This study 
concluded that an autoaated data nanageaent system could be 
iaplesented at JSC. The results of the reguirenents study 
can be found in the System Heouirefflents Docaaent for th e 
Shuttle program Inforaation Kanageaent System . 

The feasibility study identified the principle computer 
for SPIMS applications as a Control Data Corporation (CDC) 
CYBER 70 series computer. This. series of computers provides 
a distributive processing capability with both upward and 
downward software compatibility. Additional applications 
are available using the ONIVAC 1100 computer series. Unless 
otherwise stated, all interfaces described in this document 
are relative to the CDC CYBER 74 computer as the 
applications processor. The KRONOS Time-Sharing Operating 
System was selected as the terminal interactive control 
executive for the CDC CYBER 74, MRI Systems Corporation’s 
SYSTEM 2000* was selected to provide data management 
services to the SPIMS applications. The Terminal control 
System (TCS) in the Mission Control Center (MCC) was 
designated to provide data buffering and terminal network 
control. 

The requirements study provided an introduction to the 
Shuttle Program Information Management System. An overview 
of the existing capabilities of the operational systems 
hardware and software components was presented. A brief 
description of the applications within SPIMS was presented. 


^Trademark of MRI Systems, Corp. , Austin, Texas. 
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Section 3 of the STst'ea Reguireaents Docuaent for the 
S huttle Prograa Inforaation Hanaoeiaent System specified the 
requireuents placed upon each functional eleaent of the 
5PXHS. Figure 1-1 illustrates these functional elements. 
Certain requirements are currently supported, while others 
necessitated enhancements to existing capabilities or the 
development of new capabilities. 

1.2 PORPOSE 


This Systems Functional Design Document presents the 
normal actions or activities provided by each element of 
SPZMS. These generic activities are: 

• Support a mixed terminal-type environment 

• Support communications control for two basic 
protocols (synchronous, asynchronous) 

• Support an interactive multiprogramming data 
base/batch applications environment 

This document indicates the element-to-element 
dependencies to support these activities. 

1.3 DOCDMENT OVERVIEW 


This document provides a description of the functional 
capabilities and interfaces reguired for the integrated 
Shuttle Program Information Management System (SPIMS) . 

First and second level sections and paragraphs provide the 
reader with a generalized functional design of SPIMS by 
subsystem. Lower level paragraph numbers within each 
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FUNCTION SPIMS HARDWARE 
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ROCKWELL INTERNATIONAL 
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Figure 1-1, — Functional elements of SPIMS. 
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section provide the reader with a detailed functional design 
of each element within the subsystem. 

Section 2.0 provides a description of the hardware 
elements of the SPIHS and the functions these elements 
support. Section 3.0 presents the basic interfaces and 
responsibilities of each software subsystem within SPIHS- 
The functions provided by these subsystems are the result of 
incorporating enhancements with prior capabilities and the 
addition of required new capabilities. Section 4.0 provides 
an overview of all terminal data paths provided by the 
SPIJ5S. 


Section 5.0 presents a generalized SPIHS Applications 
design utilizing the functional elements of the SPIHS. 
Several design considerations are presentedi Section 6.0 
outlines the SPIHS Controllers responsibilities and the 
functions available within SPIHS to provide the monitoring 
and control these responsibilities required. Section 7.0 
provides a summary of the capabilities provided by this 
functional design. 
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2 . 0 SXSTEJl HAfiDHA SE 


2.1 SPIMS HABDHABE CONPIGOBATION OVEEVIEH 

SPIHS is an integration of four hardware subsysteas - 
the Terminal Subsystem, Terminal Control Subsystem, CTBEE 70 
Subsystem, and the DNIVAC 1100 Subsystem. Each subsystem 
supports a unigue function for the total system. These 
functions are: 

• Terminal network 

• Network control 

• Time shared-data base/Batch applications processing 

• Batch applications processing 

Pigure 2-1 illustrates the SPIHS functional hardware 
configuration. 


2,2 TERMINAL SUBSYSTEM CONFIGURATION 

The Terminal Subsystem configuration is illustrated in 
figure 2-2. Each terminal type has different functional 
capabilities. The Voice Freguency (VF) Patch Bay provides 
the ability to reconfigure the on site/off site 
communications lines to their required modern groups. 

2,2.1 Teletypewriters 

These devices transmit data, one character at a tine, 
using the American Standard Code for Information Interchange 
(ASCII). Transmission speeds range from 11 to 15 characters 
per second (CPS) . The mode of communication is half duplex. 
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Figure 2-1. — SPIMS functional hardware configuration. 


2-2 




ro 

i 

to 


E 

X 



CTM 


CTH 


CTM 


CTM 


Figure 2-2. 


Terminal 


subsystem configuration. 













The protocol is asynchronous. Character parity is odd. In 
addition to the parity bit each 8 bit character is framed 
within one start bit and two stop bits for transmission 
purposes. Thus, each character (including the framing bits) 
constitutes a ’’message” on the transmission line, 

2.2.2 Teletype (TTY) Compatible Devices 

These devices utilize the same communications mode, 
protocol and parity as a teletypewriter and provide 
transmission speeds up to 30 CPS. Terminal input/output 
(I/O) is impact printed and/or displayed on a cathode ray 
tube (CRT) . 

2.2.3 Hazel tine 2000 CRT with the Hardcopy Device Option 

These devices will operate in Batch mode using the same 
communications conventions as TTY devices. The Batch mode 
provides the following significant enhancements to the TTY 
compatible devices. 

• The ability to send or receive asynchronously from 1 
to 1,998 ASCII characters plus control bytes in a 
single transmission 

• The ability to address any character position within 
the 27-lines by 7h-character matrix 

• The ability to define from the remote computer, data 
display and data entry only areas 

• A local display edit function (e.g., insert line, 
insert character, delete line, delete character) 

• The ability to select a hardcopy of the displayed 
data independent of other SPIHS subsystems 
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An indept-h description of the Hazeltine 2000 may be found in 
the Hazeltine 2000 Operating Manual s HI1004, published by 
the Hazeltine Corporation. 


2.2.4 Hazeltine 4000G CfiT 

Each terminal unit shall be configured with the 
following; 

• A Hazeltine 4000G CRT terminal unit with 
alphanumeric, limited graphic capability and a 
detached keyboard 

• A'n optional CRT display copier hardcopy unit 

• An optional function key module 

These devices shall operate in a mode analogous to the 
Hazeltine 2000 Batch mode. The communications mode is half 
duplex. The protocol is synchronous. Character parity is 
odd. Each character is 8 bits in length. Control 
characters are added to the beginning and end of each 
character string for transmission. Thus, a ’'message” 
constitutes the two control characters and the data. The 
Hazeltine 4000G Batch mode in conjunction with the terminal 
configuration provides the following enhancements: 

• The ability to send or receive from 1 to 3,996 
alphanumeric characters plus control bytes in a 
single transmission 

• The ability to address any character position within 
the 53-lines by 74-character matrix 

• Synchronous data transmission rates of 600 CPS or 
1200 CPS 
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• User initiatied Selective Transmission of portions 
of the 53-lines by 74-character matrix. The 
starting and ending location of the character string 
on the display are automatically included in the 
message. 

• Limited graphics where horizontal and vertical lines 
can be displayed 

• The ability to transmit function codes via 96 
function keys 

An indepth description of the Hazeltine 4000G CRT may be 
found in' the C RT Terminal System Software S pe c ificati ons, 

PHO SI-09637A. 


2.3 TERMINAL CONTROL SUBSYSTEM (TCS) 

CENTRAL PROCESSOR UNIT (CPU) CONFIGURATION 

A TCS single CPU configuration is illustrated in figure 
2-3. The normal configuration for TCS provides network 
control and hardware redundancy for all elements 
illustrated. This redundancy is accomplished by configuring 
two CPU’s and their critical peripheral equipment to share 
the control function. The configuration illustrated in 
figure 2-3 is capable of assuming total terminal network 
control with a minimum observable degradation. More 
detailed information about the hardware is available in the 
S ystems Requirements Document fo r the Shuttle Program 
Information Management System , JSC-09381. 
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Figure 2-3. 


SPIMS single CPU TCS hardware configuration. 


















2.3.1 U494 Central Processor Un.it/Hemory (CPU/H) 


The CPU/M has an arithmetic, a control, and an I/O 
section. The memory units total 131,032 30-bit words. A 
parity bit is provided for each half word (15 bits) . A 
computer control console is attached to provide monitoring 
and control of the computer operations. 

2.3,2 Direct Access Storage Devices and Controllers 

Two types of direct access storage are provided by TCS; 
they are magnetic tape and magnetic drums. The magnetic 
drums are further classified as high speed or large 
capacity, 

• Magnetic tapes provide for the recording and 
retrieval of data in a sequential mode. Data is 
transferred at rates from 24,000 to 96,000 frames 
per second depending on the recording density. 

• Magnetic drums-high speed (FH432) provide for the 
recording and retrieval in a random or sequential 
mode for 262,144 30-bit words plus parity. High 
speed is provided based on an average access time of 
4.33 milliseconds and a 240,000 words per second 
(maximum) transfer rate. 

• Magnetic drums-large capacity provide for the 
recording and retrieval in a direct access mode 
(word addressable) for 786,432 30-bit words plus 
parity. This provides the large storage Capacity- 
Average access for any word is 17 milliseconds 
coupled with a 60,000 words-per-second transfer 
rate. 
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2.3.3 Printers/Card Header and Controllers 


Two printer devices are available within the TCS. 

• A 600 lines-per-minute , 132 characters-per-iine 
device 

• A 1,200 to 1,600 lines-per- minute , 132 characters- 
per-line device. 

One card reader is provided with 80 column Hollerith and 
column binarj modes. The maximum reading speed is 615 cards 
per minute. 

2.3.4 Communications line Interfaces and Controllers 

The Communications Terminal Modules (CTM*s) functioning 
in concert with their controllers govern the interfaces 
between the CPU and the devices conforming to the accepted 
standards for serial data transmission in odd parity. Two 
types of transmission devices are supported; 

• Low speed, asynchronous devices with transmission 
rates up to 30 CPS 

• High speed, synchronous devices with transmission 
rates up to 1200 CPS 

2.3.5 Computer Adapter Interface (CAI) 

The CAT provides an 81.6 thousand bits per second 
serial bidirectional channel between the TCS and the CYBER 
74 Subsystem. 
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2.4 CYBER 70 SERIES SUBSYSTEH CONFIGURATION 


A representative SPINS CYBER 74 Subsystem configuration 
is illustrated in figure 2-4. The CYBER 74 is the primary 
computer supporting time sharing and Batch processing of the 
SPINS data bases. 

The CYBER 74 Subsystem provides the resources required 
to support Bultidata bases with on-line update and retrieval 
capabilities and Batch application processing. More 
detailed information about the hardware is available in the 
Systems Reauireaents Document for the S h uttl e Program 
Information Management System , JSC-09381, 

2.4,1 Central Processor . Onit/Central Memory (CPU/CM) 

The Central Processor Unit provides 10 functional 
units. The functional units provide the multiprocessing of 
arithmetic, manipulative, and logical operations. These 
instructions are stored and retrieved as needed from Central 
Memory (CM). Central Memory (CM) consists of 131,072 60-bit 
words. The CPU to CM interface is one of two interfaces . 
supported by the Central Processor Unit. The second CPU 
interface is direct transfers- to Extended Core Storage 
(ECS) . 


2.4.2 Input/Output, Operator console Interfaces 

The CYBER 74 Subsystem provides direct channel to 
device interfaces. Figure 2-4 illustrates a channel to 
device configuration. Each channel is accessible by any of 
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the 1ft Peripheral Processors (pp*s> , Bidirectional data 
transfers are supported for each active PP/channel 
combination concurrently. 

All Inactive PP*s constitute the Peripheral Processor 
Pool. The PP>s operate independent of the CPU and 
concurrent with each other as prograomed interfaces between 
Central fleaory and the peripheral devices. Central Memory 
program I/O requests are assigned to the first available 
Pool Peripheral Processor, This PP provides channel 
selection and data transfer control independent of the CPU 
and other PP*s. 

A dedicated PP provides the interface and command 
interpreter between the Operator Console and the CPU 
monitor. 


2.4.3 Direct Access Storage Devices and Controllers 

Three types of direct access storage devices are 
provided by the CYBER 74 Subsystem * magnetic tapes, disk 
drives, and extended core storage. 

• Magnetic tapes provide the recording and retrieval 
of data in a sequential mode. Data is transferred 
at rates from 30 thousand to 240 thousand frames per 
second, 

♦ Disk drives provide a high speed random access for 
110 million characters per removeable pack* Data 
transfers occur at a maximum rate of 925 thousand 
CPS with an average access time of 44.3 
milliseconds. 
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• Extended core storage (ECS) provides the storage and 
retrieval in a direct ‘and indirect access node of 
500 thonsand 60-bit words plus parity. Indirect 
access mode transfers are supported via the 
Distributive Data Path and any PP. The CPD (being 
isolated from I/O) continues to process. Direct 
access mode transfers are supported via a single CPD 
instruction. The PP''s can access CM during an ECS 
transfer however contention may cause a one 
microsecond delay for the PP*s CH access request 

2.4.4 Printer/Card Eeader/Card Punch and controllers 

Two printers are available within the CYBER 74 
Subsystem. They support a print rate of 1,200 lines per 
minute, 136 characters per line. 

The card reader supports 80 column Hollerith and column 
binary transfer modes. The maximum reading speed is 600 
cards per minute. 

The card punch supports 80 column Hollerith and column 
binary punch modes. The maximum punch speed is 200 cards 
per minute. 


2.4,5 Serial Interface Unit (SIU) 

The SIU provides an 81.6 thousand bits-per-second 
serial, bidirectional interface between the CYBER 74 and the 
TCS Subsystem. 
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3.0 SPIHS FOHCTIONflL DESIGN 


The functional Design Document of the Shuttle Progr am 
Infor aation Hanageaent System delineates the basic 
interfaces and responsibilities of each subsystem nithin 
SPIHS. This design is the result of merging' the unigue 
capabilities of already existing subsystems and, where 
necessary, enhancing these subsystems. The requirements for 
these enhancements are found in the Systems Requirements 
Dgc^ent_f gr_the .Shuttle Program Info r mation Hanagement 
As a result of the enhanced subsystems and the 
responsibilities assigned to them, a transaction oriented 
system has been designed, 

A SPIMS transaction is defined as the process by -which 
an online system supports a programmed function to a 
predetermined conclusion. A transaction is initiated by an 
individual user. A transaction includes the input message, 
the program controlled computer processing, and the 
transmission of any output messages associated with the 
function. Figure 3-1 illustrates a SPIHS transaction and 
the generic subsystems required to assure completion of the 
action. 


3.1 TEEHINAL SUBSYSTEM FUNCTIONAL DESIGN 

The Terminal Subsystem is designed to support three 
basic functions: 


• Provide an entry to SPIHS for all terminal users. 
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FUNCTION 


SUBSYSTEMS REQUIRED 


USER INRUT/ 
OUTPUT DEVICES 


SERIAL DATA 
TRANSMISSION 


DATA ROUTING 


TRANSACTION 

PROCESSING, 

OUTPUT 

INITIATOR 



Figure 3-1. — SPIMS transaction support. 
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• Assure that appropriate telecommunications protocols 
for the serial data transmissions lines are 
provided. 

* Assure that the terminals provide timely support for 
the bi-directional transmission of large volnmns of 
data. 

These functions have been satisfied (fig. 2-2) by the 
terminals and the incorporation of high speed modems^ low 
speed modems, modem drivers, and their associated 
communications lines. This subsystem is a hardwired system 
with no computer software required. 


3.2 TERMINAL CONTROL SUBSYSTEM FUNCTIONAL DESIGN 

The Terminal Control Subsystem (TCS) is designed to 
interface a large number of diverse user-terminal devices 
with terminal applications residing in a multihost computer 
environment. In performing this function, the TCS provides 
a comprehensive set of coramunications-oriented services to 
facilitate terminal and applications communications and 
control. The following subsections describe the functional 
design of those services provided by TCS and required by 
SPIMS. More detailed information may be found in the 
Terminal Contro l System Require m ents and User*s Guide . GDSD, 
SSB-004. 

3.2.1 SPIMS Supported TCS Functional Requirements 

The Terminal Control Subsystem (TCS) will support the 
following SPIMS functions: 
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• Handshaking processing (function codes/coomands) to 
validate all user interfaces 

• Recognition and validation of terminal user and 
terminal type 

• Establishment of and continued recognition of 
terminal routing schemes 

• Circuit assurance processing to confirm a working 
interface between the user terminal and the TCS 

• Demand/response processing mode for message flow 

• Message format validation ^/assure compliance to 
predefined message headers, ^teit, and trailers 

• Message traffic accounting 

• Maintain a maximum of 42 active terminals 

3.2. 1.1 F unction Code Processin g. Fundamental to the 
design of TCS is a set of predefined function codes which 
provide the handshaking between elements. These elements 
may be divided into the following interfaces: 

• Hardware to hardware 

• Terminal to TCS 

« Terminal to application 

• Applications to network 

• Application to terminal 

Hardware to hardware interfaces are provided by the 
hardware configurations illustrated in figures 2-1, 2-2, 
2-3, and 2-4. These hardware connections must exist for 
spins to operate. 

Applications to network accesses are provided by TCS 
through the Application Initialization/Teroiination 
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Functions. Figure 3-2 illustrates these functions and the 
sequence of events required to indicate an application is 
online or not currently available to SPIHS users. 

Terminal to TCS access is provided by TCS through the 
processing of the user sent $TON,XXXX,Y command. Figure 3-3 
illustrates this sequence of events. The disabling of this 
access is provided by the command $TOF,XXXX. Figure 3-h 
illustrates this sequence. 

Terminal to application/application to terminal routing 
schemes are established by TCS using a logical data path 
concept. The logical data path (LDP) concept establishes 
the bidirectional linJc between the terminal and an 
application in the host computer. (Section 4.0 is a 
detailed description of all SPIHS LDP's.) 

The message addressing scheme used is: 
source/destination. The source code indicates the message 
initiator. The destination code indicates the message 
recipient. A unique numeric code. Externally Specified 
Index (ESI) , is assigned for each active terminal. A 
numeric code is assigned for each available SPIHS 
application. Thus, each terminal user of SPIHS has a unique 
terminal-application code combination. The position of 
these codes in the TCS message header establishes the 
direction TCS is to transmit the data. Figure 3-5 
illustrates the functions performed by TCS to establish and 
maintain the data routing scheme. Figure 3-6 illustrates a 
TCS data flow utilizing the established LDP's. Figure 3-7 
illustrates a TCS data stream overview to SPIHS. 
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INITIALIZATION 

Q APPLICATION INITIALIZATION 
^ PEQUEST (FC121) BY 
APPLICATION ID 

TCS VALIDATION OF 
APPLICATION ID 

APPLICATION INITIALIZATION 
CONFIRMATION (FC122) OR TCS 
TO HOST ERROR (FC175) 
MESSAGE: "APPLICATION ID 
MISSING, APPLICATION ID 
INHIBITED" 


TEPJyilNATION 

@ APPLICATION TERMINATION 
REQUEST (FC124) BY 
APPLICATION ID 

Q TCS VALIDATION OF 
APPLICATION ID 

(D APPLICATION TERMINATION 

^ CONFIRl'UiTION (FC125) OR 
TCS TO HOST ERROR (FC175) 
m S SAGE : " APP LI CAT I ON 
NOT INITIALIZED" 


Figure 3-2. — TCS application initialization/termination 

function code processing. 
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*XXXX = TERMINAL USER ID 

Y = DEVICE TYPE 1 - H4000G SYNCHRONOUS 
DEVICE TYPE 2 - H4000G ASYCHRONOUS 
DEVICE TYPE 3 - H2000G ASYCHRONOUS 
DEVICE TYPE 4 — TTY COMPATIBLE ASYCHRONOUS 

(I) Illegal user ID or terminal type causes 
nonconfirmation 


Figure 3-3. - Terrainal-to-TCS access with $TON,XXX,Y command. 
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*XXXX = TERMINAL USER ID 


Figure 3-4. — Terminal- to TCS disconnect with $TOF,XXXX command. 
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Figure 3-5. - TCS DATA ROUTING SCHEME 







Figure 3-6. — TCS data flow utilizing LDP's 
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Figure 3-7. — TCS data stream overview 




3 . 2 . 1 . 2 Demand/Hesponse Processing Function • This 
function, in conjunction with the TCS capability to 
interleave messages, provides control of data transfers 
among the various elements of SPIMS. Demand/response 
processing provides the message load leveling required by 
SPIflS to interface the applications executing in the CYBES 
74 Subsystem with terminal users operating at various slower 
transmission line speeds. ‘ See figure 3-8 . 

Each user terminal within SPIHS is processed by TCS as 
a «free wheeling" input device. i "free wheeling” 
terminal’s input is not computer controlled, TCS must 
buffer the input from start of Transmission to end of 
transmission. Data is collected into fixed message blocks 
and transmitted to the host computer in an interleaved, 
segmented fashion. Figures 3-9 and 3-10 illustrate this 
interleaved, message blocking transmission technique for 
both directions. 

3 . 2 . 1 . 3 M essage Format Vali d ation and Accounting . The 
message format validation function of TCS consists of 
software checks to assure the followxng: 

• .An LDP exists 

« Proper header and trailer data envelope the message 
block 

Failure of either of these conditions will cause TCS to 
issue a diagnostic to the sender. 
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HOST COMPUTER 



THIS CONTROL SEQUENCE IS REQUIRED FOR ALL OUTPUT 
MESSAGE BLOCKS: 

Q NORMAL DATA SEND (FIRST MESSAGE BLOCK) 

SOURCE = APPLICATION ID 
DESTINATION = TERMINAL ID 

DATA MESSAGE BLOCK TO TERMINAL 
(ONE 351-CHARACTER BLOCK) 

^ DEMAND REQUEST 

SOURCE = APPLICATION ID 
DESTINATION = TERMINAL ID 

NORMAL DATA SEND (SECOND MESSAGE BLOCK) 

SOURCE = APPLICATION ID 
DESTINATION = TERMINAL ID 

Figure 3-8. — Demand/response data flow host computer to terminal. 
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Figure 3-9. - CYBER-to-TCS interleaved interface. 
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Figure 3-10. — TCS-to-CYBER interleaved interface. 
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Message accounting within TCS provides software 
trapping of messages to a logging file before forwarding 
this data to its designated destination. The message 
logging function is option driven* 

3.2.1.^( Circuit Assurance . This function permits the 
terminal user to validate the integrity of his 
communications line connections to- TCS. Pigure 3-11 
illustrates the TCS circuit assurance data flow. 
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$ START LOOP TEST 

IF AN LDP EXISTS; LDP BUSY MESSAGE 
@ INPUT DATA ) 

> MULTIPLE TRANSMISSIONS MAY OCCUR 
@ ECHO DATA ) 

(D ? END LOOP TEST 

(D IF AN LDP EXISTS: LDP RESUME 

@ IF OUTPUT PENDING, TRANSMIT FIRST BLOCK 

(D $ LDP SELECT (APPLICATION) /$SON, APP. ID (SEE SECTION 4.0) 
0 IF OUTPUT PENDING, TRANSMIT FIRST BLOCK 


Figure 3-11 


TCS circuit assurance sequence of events 











3.3 CrBEB 74 SOBSTSTEM FUNCTIONAL DESIGN 


The CYBER 74 Safasystem supports the following generic 
functions; 

♦ Low speea/high speed terminals 
Resource shared program processing 

♦ Opdate/retrie val data base access 

♦ Nonterminal oriented applications processing 

3.3-1 CYBER 74 Core Heraory 

Figure 3-12 illustrates the CYBER 74 central memory 
(CH) configuration during TCS support. Figure 3-13 
illustrates the CYBER 74 CH configuration during non-TCS 
support. Control point (CP) designates the location in CM 
for a program at a given point in time. Additional 
information about the CP concept may be found in section 
3. 3.2.1 of this document and section 2.3.2. 1 of the S yste m 
Re quirement s D ocument for the Shuttle Program Information 
Management System . 

3.3.2 KRONOS Time-Sharing System Functional Design 

KRONOS is a complex operating system containing many 
features. KRONOS is designed to provide support for a mixed 
processing environment. The primary purpose of this section 
is to describe the functional design for job processing. A 
job’s processing class in this environment is defined by the 
origin of the job. 
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wm ^ -|- IT m i 

NONCOMMON S2K DATA BASE CODE (THREAD 1) 
Control Point n (n<23) 

I 

AVAILABLE FOR 

DATA MANAGEMENT/NONDATA MANAGEMENT 
TRANSACTIONS AND BATCH PROCESSING 


*A PSEUDO CONTROL POINT 

Figure 3-12. — CYBER 74 CM configuration {KRONOS-TCS support) . 
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Control Point 30* 

SYSTEM POINTERS AND CONTROL WORDS 

PERIPHERAL PROCESSOR COMMUNICATIONS AREA 

CENTRAL PROCESSOR UNIT MONITER 

PERIPHERAL PROCESSOR, » CM RESIDENT LIBRARY 
Control Point 1 

APPLICATION/DATA MANANGEMENT PROCESSING 
Control Point 2 


APPLICATIONS/DATA MANAGEMENT PROCESSING 


Control Point n (n"^23) 
APPLICATIONS/DATA MANAGEMENT PROCESSING 
*A PSEUDO CONTROL POINT 

Figure 3-13. — CYBER 74 CM configuration (KRONOS- 

non-terminal support) , 
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SPIHS has the followiEg Job origins: 


• Tiie-sharing (interactive) 

• Local Batch 

• System console 

Figure 3-14 illustrates the generic input/output (I/O) 
paths for the three job origins* Efficient priority 
processing of job origins is the primary objective of 
KBOUOS. This section describes the basic software elements, 
their functions, and how these, software elements working 
together accomplish the prime objective. Additional 
information is available in the Co ntrol Dat a _ KRON OS 2 .1 
Horkshop Reference Hanual , Control Data Corp., 97404700B, 

Hay 15, 1974, and the SPIHS/GYBEB Interface Cont rol 
Document , Control Data Corp., 90CLKA00021-1 , January 31, 
1975. 


3.3.2. 1 K RONOS d efinitions . Several hardware/software 
terms are basic to the functional design of KSONOS. An 
explanation of these terms and their capabilities is 
required to clarify the functional design of the KRONOS 
Time-Sharing System. 

3.3.2. 1.1 Job origin type/gueue priority (JOT/QP) : 

Each job entering the RRONOS controlled environment is 
assigned a job origin type and a queue priority. The SPIHS 
job origin types are: 


IXB® 

SYOT 



System console - all jobs initiated via the 
system console. 
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SYSTEM 

CONSOLE 




Figure 3-14. — Job origin input/output paths. 
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SCOT 


Local batch - jobs entered from all local 
batch devices, or Initiated by the terminal 
command SDBBIT. 

TX02 TELEX/ICE - jobs entered via the time- 
sharing executive program TELEX/ICE. 

RIOT A job doing one specific task for many 

terminals. These jobs provide global pre- 
processing of time sharing jobs in a collec- 
tive manner. 


Scheduling parameters for jobs are established and 
aged based on the job origin type and queue 
priority. 

Basically the job origin type sets the priority for 
a job request for central memory control points; 
queue priority sets the priority for servicing a 
control point program request for the central 
processor. These parameters are installation 
options. The standard KEO^IOS priority order for 
SPIHS job origin types/queue priorities is: 


Job Origin 

Type 

MTOT 

SYOT 

TXOT 

BCOT 


G eneri c (QP ) 
First 
Second 
Third 
Fourth 


3.3,2. 1.2 Control point: A control point is that area 

of central memory allocated to a job »hile the job is 
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executing,, waiting I/O coapletion, or requiring the CPU. 

This area o£‘ central senory is bounded by a reference 
address (8A) within central aemory and a block length or 
field length (FL) Also associated with each control point 

is a 200 word area of neaiory. This block is called' the 
Control Point Area (CPA) . The CPA contains accounting data, 
a buffer for the registers, priority, a control card buffer 
and user validated capabilities. This area is rolled out 
with the control point. 

The FL for a job is allocated in consecutive 100 
octal-word blocks. See Figure 3-15. Control points 
are assigned independent of an applications previous 
control point assigntaent. Subsystems, however, 
reside at designated control points and control 
their own subcontrol points. ' 

A control point contains a job*s central processing 
instructions to operate on data and the peripheral 
device reguests required to read and output data- 
The first 77 octal-words of a control point are used 
for communications to three ppu programs, I/O buffer 
pointers, and the current control card to be 
executed. 

Because the CPU cannot read or write to peripheral 
devices, no central memory is required for 
perhiperal device drivers- 
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NOTE: See figure 3-12 for SPins core 


TIME-SHARING MULTIPROGRAMMING CM ‘ 

CONTROL POINTS ADDRESS 



map. 


Figure 3-15. — Control points. 
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Begaes'ts for I/O and other systen services are 
placed in the second word of a control point fay the 
application. These requests are called R^+^ 
requests. These requests are recognized by either 
of the KRONOS monitors. Central Processor Monitor 
(CPOMTB) or peripheral processor (PP) Monitor (KTE) 
and the scheduler, TSJ. 

The allocation, servicing, and management of control 
points by the KROHOS monitors provide a time- 
sharing, multiprogramming environment. Section 
3.3. 2. 2 describes the basic functions these monitors 
perform. 


3. 3. 2. 1.3 KROROS Subsystems: Subsystems are 

considered special jobs with many privileges not granted to 
regular jobs within the system. Some of these privileges 
are: 

• Subsystems cannot be rolled out. 

• Subsystems can make use of the intercontrol point 
communications request (SIC/RSB) to receive and 
send data buffers. The SIC will be used to receive 
data in the System 2000 Multiuser Multithread 
Executive. 

• Subsystems may divide their control point into 
subcontrol points. 

• Subsystems may be assigned a central processor 
unit (CPU) request priority above normal control 
point jobs. 

• Subsystems need not be restricted by the standard 
job control parameters defined to the KROHOS CPO 
monitor. 
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• Subsystems execute at a predefined control point. 
Thus, at load tine any job at that control 
point is moved. 

Job advancement, scheduling, and detection of 
subsystem requests by KBONOS is different than for a 
normal job (see section 3.3.3). The scheduling 
routine 1SJ must trap a subsystem in order to ensure 
its requested control point immediately and assign 
its unique CPO priority. . This priority is normally 
very high, thus, caution should be used in all 
subsystems to avoid dominant use of the CPU. 

3.3.2. 1.4 Subcontrol Points: as the name implies, are 

divisions of a Central Memory Control Point (see figure 3- 
12, control point 2): A control point can be established to 

contain two or more programs; one of these is designated as 
the "Executive" (subsystem) which monitors the other 
programs known as subcontrol points. 

The Executive controls its subcontrol points in much 
the same manner that the system monitors manage the 
control points, Hhen a control point makes a system 
request, exceeds its time limit, or makes an error, 
control is given back to the system monitor. 
Similarly, when a subcontrol point makes a system 
reguest, exceeds its time limit, or makes a CPU 
error, control is given back to the Executive, The 
Executive sets up each subcontrol point so that, 
within the field length of the control point, each 
subcontrol point has its own "RA" and "FL" and 
cannot go outside its boundaries. The Executive is 
thus protected from access by the subcontrol points. 
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whereas the Zxecntive*s Hi and FL define the fall 
control point so the Executive can watch over and 
control all subcontrol points within the field 
length. 

The subcontrol point concept depends entirely on the 
Executive program's handling of the sabcontrol 
points. This involves starting, stopping, error 
processing, and other functions similar to those of 
the system monitor. 

Just as the system monitor keeps track of each 
control point through the control points exchange 
package, the Executive can control the subcontrol 
points through the subcontrol points exchange 
packages. The Executive is responsible for setting 
■up an exchange package for each subcontrol point; 
each exchange package, must have the appropriate RA, 
FX, program address, register settings, etc. for the 
subcontrol point* These exchange packages must be 
set up somewhere within the Executive's field length 
but probably not within the field length of the 
subcontrol point. To start execution of a 
subcontrol point, the Executive uses a CPO-to- 
monitor (XJP) reguest which indicates the address of 
the exchange package area of the subcontrol point to 
be activated. when CPDMTB picks up the reguest, it 
terminates the Executive and activates the 
subcontrol point described in the exchange package 
area indicated in the XJP request. CPUHTR also sets 
a flag in the control point area showing that at 
this control point a subcontrol point is now active. 


3-28 



Once activated, a sabcontrol point runs until (1) it 
makes a CPU error, (2) it exceeds its time limit, or 
(3). it makes an RA+1 request. Onder any of these 
-three conditions, control is given back to the 
Executive, 

The Executive can thus monitor processing for the 
subcontrol points. Errors can be noted and examined 
without termination of the control point. Upon 
returning control to the Executive, certain 
information is set up in the X registers of the CPD: 

• {X2) - msec before this subcontrol point began 

• (X6) ~ error flag and BA of this subcontrol point 

• (X7) - msec used by this subcontrol point 

One of the parameters on the XJP request is the time 
limit for the subcontrol point. Hhen this time 
limit is passed, control goes back to the Executive. 

When a subcontrol point makes an RA+1 request, 
control is returned to the Executive; the Executive 
can then decide whether to (1) ignore the request, 

(2) handle the request itself, or (3) pass the 
request' on to CPOETR using EA+1 of the Control Point 
Executive, 

3.3,2. 1,5 User Load Leveling (rollin, rollout): A 

time-sharing, multiprogramming environment assumes the 
sharing of a set of resources in an equitable manner among 
the various users. KHONOS provides this capability using a 
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co«binatioQ of rollout files, queues, priorities, and time 
slicing. 


All information pertaining to a job*s accounting, 
resource requirements, current CPU register 
contents, and program code is dynamically maintained 
in a rollout file whenever a job swap occurs. A 
rollout file is allocated and released on an as-need 
basis, one for each user of the system. Figure 3-16 
illustrates the format of a rollout file. 

The queues maintained and checked by the KRONOS 
monitors are not unique areas of core. The File 
Hame Table (FKT) provides a dual role. Hhen a 
central memory program first enters the system, the 
FNT indicates a new job is waiting and its initial 
priority. When the program is executing, the PUT 
indicates the files required, their logical names, 
and their types; i.e., input, output, local. 

When a control point program is rolled out, the FNT 
indicates that a job is in the system and what its 
priority is. Thus the PNT provides a queue service 
and a resource allocation service. 
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ACCOUNTING DATA 


RESOURCE REQUIREMENTS 
(CM, TAPES, DISK FILES, ETC.) 

CPU REGISTER CONTENTS 

CONTROL CARD BUFFER 


SYSTEM SECTOR 


TERMINAL OUTPUT 

ONLY USED WHEN THE 
JOB IS INTERACTIVE 


JOB FIELD LENGTH 
(PROGRAM CODE) 


Figure 3-16. — Rollout File Format. 
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When a is being checked, a search of the FNI 

occurs to find those entries that have the file name 
and type being sought but not assigned to a control 
point. Changing the file name or type in the Fun 
changes the queue. Figure 3-17 illustrates this 
process. 

Priorities are assigned based on job origin type. 
Queues are searched by priority. The priorities 
assigned to a job origin type are checked by the job 
scheduler against a predefined set of time slices 
and resource usage parameters. The aging of one or 
more of a job’s parameters is independent of the 
job’s activity. Age limits will vary according to 
the joij’s origin type. Jobs rolled out are aged 
concurrently with jobs at control points. Figure 3- 
18 illustrates a typical queue priority scheme. 

3.3.2. 1.6 Recall: The recall program status is 

provided by KRONOS to enable efficient use of the central 
processor and to capitalize on the multiprogramming 
capability of KRONOS. Whenever a control point program must 
wait for the completion of an I/O operation before more 
computations are performed, the control point program asks 
KRONOS to place the control point into recall. Recall may 
be automatic or periodic. 

Automatic recall can be used whenever a program 
requests I/O or other system services and cannot 
proceed until the request is complete. The CPU is 
assigned to execute a program at some other control 
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FNT ENTRY 


JOBNAME 

I 

0 


INPUT 

I 

CP 

NO. 


JOBNAME 

R 

0 


INPUT 

R 

CP 

NO. 


JOBNAME 

0 

0 


JOB STATUS 

JOB IN INPUT QUEUE (FILE TYPE) 

JOB AT CONTROL POINT 
(FILE INPUT REQUIRED) 

ADDITIONAL FNT ENTRY MAY BE GENERATED 
BY THE JOB. THESE ENTRIES ARE WRITTEN 
IN THE SYSTEM SECTION OF THE ROLLOUT 
FILE. 

JOB IN ROLLOUT QUEUE 


JOB IS ROLLED IN 
(PROM ROLLOUT FILE) 


JOB IS COMPLETE 
(OUTPUT FILES READY) 


Figure 3-17. — File Name Table (FNT) usage. 
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SYOT TXOT SCOT MTOT SYOT TXOT BCOT MTOT SYOT TXOT BCOT MTOT 


JOB ORIGIN TYPE 


LEGEND: 

SYOT - SYSTEM CONSOLE 

TXOT - TIME-SHARING 

BCOT - LOCAL BATCH 

MTOT ” MULTI-TERMINAL 

UQP - UPPER QUEUE PRIORITY SETTING 

IQP - INITIAL QUEUE PRIORITY SETTING 

LQP - LOWEST QUEUE PRIORITY SETTING 


Figure 3-18. — Typical queue priority schedule. 


3-3 4 



point. The KHOSOS CPUHTfi will not assign ,the CPU to 
a control point in automatic recall until the 
program request is complete. 

Periodic recall can be used whenever the control 
point program is waiting for any one of several I/O 
requests to be complete. The program will be 
activated periodically, so it can determine which 
I/O request has been satisfied and whether or not 
the control point program can proceed. Concurrent, 
multiple data transfers from a single control point 
program are provided by periodic recall. 

3. 3, 2. 2 KROKOS monitors . There are two monitors. One 
monitor is loaded in Peripheral Processor Zero and is called 
PP^Monitor (MTE) . A second monitor is CH resident at pseudo 
Control Point Thirty and is called CPU-Monitor (CPUMTR) . 

MTE performs the following basic functions? 

• Maintains the Beal Time Clock 

• Processes nonpriority PP requests 

t Allocates central memory 

• Checks the CPU for arithmetic errors 

• Checks RA+1 of active central point programs for 
system requests 

• Checks the status of active control points and 
initiates 1AJ (job advancement) if zero status or 
rollout status occurs 
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Checks the output register of each pool PP 


CPOHTR perforis the following basic functions: 

• Processes priority PP requests 

• assigns the CPO to control points 

• Initiates 1SJ {job scheduler) 

« Checks sa+1 of active control point programs for 
systein requests 

• Performs direct Extended Core Storage (ECS) 
transfers 

• Reserves and clears mass storage allocation tables 

• Performs central memory storage moves to provide 
contiguous unused core 

These monitors, working in concert, control the 
scheduling of all PPU programs required for job processing. 

3,3.3 KRONOS Job Processing Functional Design 

all jobs which flow through the system, regardless of 
job origin type, will be processed from initiation to 
completion by each of the following PP programs: 


Same 


Function 

1SJ 

Job 

scheduling 

lAJ 

Job 

advancement - control card 

ISP 

Job 

priority and queue ageing 

1B0 

Job 

rollout 

1RI 

Job 

rollin 
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ICJ Job termination (TELEX-ICE provides this 

function for interactive jobs) 

Eignre 3-19 illustrates a general system flow for a job 
entering the system. 

Jobs enter the system at the initial queue priority 
(IQP) for their type (fig. 3-20). They are aged by ISP as 
they reside in the input queue; i. e., the queue priority is 
increased until it reaches the upper queue priority (OQP). . 
Figure 3-18 illustrates a typical queue priority scheme. At 
any time, the scheduler, 1SJ, may determine that this job is 
the best candidate (best job) for a control point, and the 
scheduler attempts to schedule or assign it to a control 
point (fig. 3-21). This (best job) decision is made by an 
algorithm that takes into account queue priority and 
resources desired (FL, etc.) , 

In order to schedule or assign a control point, 1SJ 
determines if there is enough unused noncontiguous core 
available to satisfy the field length requirements for the 
job. If not, 1SJ will determine if there will be enough 
unused core after scheduled rollouts of other jobs. If not, 
1SJ will attempt to schedule any other jobs with lower 
priority than the best job. 
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INPUT QUEUE - LIST OF 
JOBS TO BE PROCESSED 



OUTPUT QUEUE - LIST OF JOBS 
TO BE DISPOSED 


Figure 3-19. — General system flow. 
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*TXOT/MTOT ARE STARTED 
BY TELEX- ICE AND SYOT 
IS INITIATED BY THE 
SYSTEM CONSOLE 


Figure 3-20. — Read card reader 
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Assuming enough FL, -ISJ looks for an available control 
point. If there is no control point, rollout will be 
scheduled for any job whose priority is lower than the best 
job. If there are no lower priority jobs, ISJ drops out 
until rescheduled by CPOMTR. 

When ISJ assigns the best job to a control point, it 
will get the FL and set up the control point area (CPA) with 
information from the predefined user resource validation 
tables. (These tables contain the resource maxim.ums for a. 
user.) In addition, ISJ will set the input gueue priority 
to UQP regardless of what its value was when this job was 
picked. ISJ will leave the job without an operation status 
and call 1AJ (fig. 3-22) . 

The job advancement routine, lAJ, will note that the 
job status is empty; i.e. , the last operation is completed 
(in this case, first operation is not started) , 1AJ will 
start this job. The job can at anytime create local files. 
If the file name is OUTPUT PUNCH PUNCHB or P8, the file 
will be given special treatment at job completion time (fig. 
3-23) . 

As the job progresses, one of three statuses is 
defined: wait for CPU ”H", recall ”X” , or auto-recall 
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OPTIONAL 


CPA 



Figure 3-23. — Job creates local file name OUTPUT, 
PUNCH, PUNCHB, or P8 as denoted by OUTPUT. 




CPUMTR and H’TE will periodically check all the jobs running 
at control points and, if either laonitor detects *’i,” 
and ”R” status *zero, they nill call lAJ. If the error flag 
is set, 1AJ will process the error. If the error is not 
fatal, 1AJ will advance to the next control card. If the 
error is fatal but an EXIT card exists, then 1AJ will 
advance to the control card' following the EXIT card. 

CPUMTR and MTS also monitor the CPU time-slice, and if 
the job exceeds its time- slice, its queue priority is 
dropped to the lowest queue priority (LQP) of that type. 

This does not mean that the job will lose its control point. 
If 1SJ finds a best job in the input or rollout queues, then 
low priority jobs are candidates for rollout. Also 1SJ 
examines all the control points, and if it detects that the 
CPU time-slice is exceeded before either monitor detects 
this, 1SJ will lower the queue priority to LQP, An 
interlock is provided so the queue priority is only dropped 
once. 


1R0 may be called by 1AJ, 1SJ, from the system console, 
or by a subsystem {fig. 3-24). 1R0 will dump the job 

according to the rollout file format {fig. 3-16) ; will set 
"W" “X” or **R” status to zero; will request the control 

point be made available; and will release all FL, and all 
File Name Table {FNT) entries assigned to this control 
point. 1E0 will release everything else except the input 
and control card file and will call 1AJ to advance the job. 
In this way, FNT space is not wasted while a job is rolled 
out. The job is then placed into the rollout queue with 
whatever queue priority the job had when it was rolled out, 
or the rollout queue priority if two or more of the aging 
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paraneters have expired. If 1E0 is called by a subsystem 
(e.g.y S2KMH Executive) , the rollout file will be called DM* 
and left assigned to this control point, 

1BI will read the rollout file and reestablish all the 
files, equipment, etc, to allow the job to continue (fig, 3- 
25) , It will set and ”8” statuses to their former 

values. The control point will now be a candidate for the 
CPO, 


When lAJ detects an end-of-job card stream, a fatal 
error with no recovery, an illegal control card,' or some 
other fatal condition, it calls ICJ to complete -the job. If 
any of the job flow routines ever detect a type which is not 
defined (i.e., type not SYOT SCOT TXOT or MTOT) , it will 
call ICJ immediately to end the job. ' This is protective 
coding. 

ICJ will locate OUTPUT, the local file assigned to this 
job, if it exists (fig. 3-26) . It will then append the job 
accounting to the end, write an end-o£-inf oroation, and move 
the file to the output queue. This file is renamed with the 
job name for local printing. 
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OPTIONAL 


CPA 



Figure 3-24 



MAY OR MAY NOT 
BE SAME FNT/PST 
ENTRY 


MAY OR MAY NOT 
BE SAME FNT/FST 
ENTRY 



ANY OTHER LOCAL 
FILES 


Job is rolled out 
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CHANGE OUTPUT FILE NAME TO 
JOBNAME AND TYPE FROM L TO 
0. APPEND DAYFILE ONTO END 
OF OUTPUT FILE. 

ICJ ALSO RETURNS ALL FILES 
ASSOCIATED WITH THIS JOB 
EXCEPT OUTPUT TYPE PILES 


Figure 3-26 


Job completes 




3.3.4 Teriainal Support Software ('TELEX-ICE) 
Functional Design 


The- SPIES CYBEB 74 Terminal Support Software (TELEX- 
ICE) is a KHONOS subsystem. This subsystem provides the 
interface and control of interactions between KHONOS and the 
user at an interactive terminal. 

Two communications hardware/software interfaces are 
supported by TELEX-ICE. Figure 3-27 illustrates these 
interfaces. 

Two data transmission modes are supported by TELEX-ICE: 

• Normal Mode 

• Special Binary Mode 

Normal Mode data transmissions from the terminal are 
constrained to be no greater than 150 characters per read 
reguest. Normal Mode output to the terminal does not have 
this constraint, TELEX-ICE provides the controls required 
to assure correct transmission of all data to the terminal. 

Special Binary Mode (SBH) data transmissions are 
constrained to be no greater than 5400 characters per 
transmission in either direction. Section 4.0 contains a 
detailed explanation of the initiation and use of these two 
transmission modes by applications and terminal users. 

3 . 3 . 4 . 1 Termina l Support Software Elements 
(TELEX-ICE) . The TEIEX-ICE subsystem consists of a central 
processor (CP) program and several peripheral processor (PP) 
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Figure 3-27. — TELEX- ICE coiiununications hardware/software interfaces 






prograas. The names and basic functions of these software 
elements are: 

TELEX - Terminal Executive Initialization Routine, 

This routine is loaded in response to a system 
console reguest, TELEX initializes tables and 
pointers and loads TELEX1. 

TELEX1 - Terminal Executive Processor. TELEX1 is the 
main routine that processes I/O for the 
terminals using normal mode. TELEX 1 cracks 
and processes commands and makes requests to 
dump source input to disk and refill output 
buffers from disk for Normal Bode -I/O. TELEXI 
in concert with 1TD interfaces directly with 
the CDC 6676 multiplexer. TELEX1 operates 
with ICE to support the high-speed interface 
to TCS. 

TELEX2 - Terminal Executive Termination Routine. 

TELEX2 is executed after detection of an 
abnormal condition in TELEX or the system 
console request 1.ST0P which terminates the 
TELEX subsystem. 

ICE - ICE is a SPINS enhancement to TELEXI and is 
required to support the high speed 
communications interface with TCS and Special 
Binary Mode I/O, 

ITfi - TELEX Auxiliary Function Processor. This 

routine processes functions for TELEX which 
require PP action. 

1TD - Terminal Communications Driver. Low speed 

interactive {600 baud or less) . 1TD performs 
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character code coaversion and communications 
betveen TELEZ1 and the CDC 6676 multiplexer. 

ICE - Computer-to-coaputer interface driver. ICS 

supports high speed data transfers (81.6 Kbps) 
between the *TCS and the CYBES 74. 

1TO - Terminal input/output. 1TO is called by TELEX 
, to perform terminal I/O requiring mass storage 
accesses. 

PPM - Permanent File Manager. PPM may be called by 
TELEX to process Permanent Pile requests. 

TELEX processes some PPM calls himself. 

CIO - Common input/output. CIO is called by ICE to 
process Special Binary Mode data. 

1UP - ICE calls 1UP to find the File Name Table 

entries of the Special Binary Mode files for 
jobs rolled out. 

The relationship between the various CP and PP routines 
is shovn in figure 3-28. 

3 . 3 . 4 . 2 KHQHOS supp or ted t ermina l input/output 
( TELEX-ICE^ . There are three terminal I/O support functions 
provided by TELEX-ICE; 

• Primary File used to construct source code programs 
in Dormal mode. 

• Rollout File used to buffer code converted multiline 
data for an applicatons user. 

• special Binary File used to buffer SBM data for an 
applications/user. 
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TELEX 

ASSISTANT 


TERMINAL I/O 
NORMAL MODE 


COMMON I/O 
SPECIAL 
BINARY MODE 


PERMANENT 
FILE MANAGER 


SPECIAL 
BINARY MODE 
PNT ENTRY 


Figure 3-28. — Terminal support software relationships 




Figure 3-27 illustrates Priiary File and Rollout File 
I/O, • During interactive normal node input processing, the 
terminal data is buffered in POTS by 1TD or LPOTS by ICE. A 
•POT is an eight-word central meaory buffer allocated by 
TELEl, The LPOT is a 48-word central memory buffer 
allocated by ICE. Each IPOT is edited (deletion of TCS 
message envelopes) and converted to display code by ICE. A 
normal mode LPOT contains a maximum of 150 data characters. 
Characters not in the 63-character display code table are 
deleted. This data is then established as a POT for TELEX- 
1TO processing. 

During Primary File processing, each POT (terminal 
line) of data is transferred by 1TO to mass storage, one POT 
per physical dish address (sector) within the file. During 
output processing, the Primary File Is compressed by packing 
all statements together. 1TO reads the Primary File from 
mass storage and stores the data in POTS for 1TD or ICE/ICE 
output processing. 

Daring Rollout File processing, the input data is 
transferred directly to a control point program input buffer 
from the POT by 1TO. During output processing, the first 
eight words of data are transferred directly from a control 
point program output buffer to a POT, Additional output is 
buffered in the system sector of the Rollout File (see fig. 
3-16) for subsequent transfer to POTS by 1T0. Special 
Binary Mode request or status data is transferred directly 
from a POT to a control point program. 

3 . 3 . 4 • 3 Generalized interactive job initiation , Refer 
to figure 3-29 for this discussion. Assuming that a 
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PILE NAME TABLE 



Figure 3-29. — Generalized interactive job initiation 







$s6n, has been received by T£LEX~JCE, the following 

sequence of events occurs. 

• TELEX-ICE builds a Procedure File control card and 
an FNT entry in a POT and calls 1TA. 

• 1TA establishes a rollin queue entry in the system 
PUT table. This entry points to a Rollout File^ the 
Procedure File control card/data EOT and the FNT 
entry POT, 

• ISJ, the scheduler, determines that this job is the 
”best job" to initiate. 1SJ assigns a control point 
and calls 1SI to roll in the job. 

• 1KI reads the Rollout File, initializes the control 
point, sets up the Control Point Area at control 
point zero, and calls 1AJ. (1AJ is not called to 
restart an already initiated ' job. ) 

• 1AJ advances the job {i.e., reads a control card), 
detects the procedure file call, and loads the 
requested application. As the application executes, 
it interacts with the terminal user. 


3 , 3 . 4 . 4 Terminal job inter a ction - output . Only LDP ' 
Type 1, Hormal Mode, is discussed here. Applications 
writing to the terminals via Special Binary Mode are 
constrained to the following standard system input/output; 
convention. Normal Mode is used to notify TELEX-ICE that a 
Spdcial Binary Mode File exists and what services 
{read/write) the application requests. Thus, the following 
sequence of events occurs regardless of the mode or LDP 
type. Refer to figure 3-30 for this discussion. 
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• This job issues a write request to the terminal. The 
Common Input/Output (CIO) Processor senses that this 
is an interactive job and issues a request to roll 
out the control point. 

• IfiO initiates the rollout and copies the entire 
field, length {including output data) to the rollout 
file. 1R0 reads the first sector of output data 
into a special buffer in its PP, 

• ITO is loaded into the same PP as IRO. The special 
data buffer is ready to be transferred to TELEX 
POTS. 

• 1T0 stores this output data into TELEX POTS and 
notifies TELEX that terminal output is ready. 

• TELEX notifies either 1TD (CDC 6676 multiplexer) or 
ICE that output data is ready. 1TD transfers the 

• data to the terminal. ICE checks the first two six- 
bit characters to determine Normal or Special Binary 
Mode data. Normal Mode data is code converted, 
given the proper network message envelope, and 
transmitted to the terminal. Special Binary Mode 
data is located via 10P and is read from its file, 
one message segment at a time, and transmitted to 
the terminal. No code conversion or message 
enveloping is generated. 

After all output is transferred, TELEX calls ITA to 
reinitiate the job. Section 3 .3. 4. 3 describes this 
function. 

3.3. 4. 5 T erminal lob interaction - input . Assuming 
that a job is to receive data from a terminal, the following 
sequence of events occurs (see fig. 3-31): 
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CONTROL POINT 



*ICE CALLS lUF TO LOCATE THE SBM FILE'S FNT IF IT IS ROLLED OUT. 

Figure 3-31. — Generalized interactive job -- input 





























• The job issues a read request: on the input file. 

CIO is called. CIO senses this job is interactive 
and issues a rollout request. 

• 1R0 is loaded and executes the rollout operation. 

1R0 then calls 1T0. 

• 1T0 checks the Rollout File. to assure that all • 
output is transmitted. If there are any Special. 
Binary Mode request codes to be passed, this check 
forces them to be passed (see section 4.6). 1TO 
then informs TELEX that the job is ready for input. 

• TELEX notifies either 1TD or ICE that an input 

request has occurred. 1TD issues the prompt 
character ICE checks the current request code. 

If Special Binary Mode is requested, no prompt is 
issued. If Normal Mode is requested, ICE issues a 
prompt ♦*?«. 

• 1TD accepts one character at a time from the 
terminal, code converts it, and stores this data in 
a TELEX POT. A carriage return code causes 1TD to 
nofity TELEX that input is complete. 

• ICE accepts data, a message segment at a time, and 
stores this data in an ICE LPOT. An end- of -message 
indicator in the message head notifies ICE that 
input is complete, 

• ICE checks the input mode for each read request. If 
Normal Mode is set, ICE strips the network message 
envelope off and code converts the data. This data 
is then transferred to a TELEX POT, and TELEX is 
notified that input is complete. If Special Binary 
Mode is set, ICE transfers the data to the Special 
Binary Mode File. When the last message segment has 
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been transferred to the SBM Pile, ICE builds a TELEX 
POT with status inf ornation, and TELEX is notified 
that input is coaplete. 

• TELEX calls 1TA to reinitiate the job. Section 
3. 4,4.3 describes this function. 

3.3.5 S2KHM Executive 
This section is to be provided later. 
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4.0 spins LOGICAL DATA PATHS 


A spins Logical Data Path (LDP) is an extension of the 
defined logical data path (source-host cooputer) for TCS to 
illustrate the primary software/hardware interfaces for a 
SPIHS tefninal/application, 

4.1 SPIHS LDP TIPES 

The LDP's for SPIHS are defined to permit • distributed 
processing control of the. functional requirements of an 
application within the CYBER 74. These functional 
requirements may be generically defined as follows: 

• Terminal interaction (LDP Type 1) 

• .Data base access, terminal interaction (LDP Type 2) 

SPIHS IDP Type 1 is a KRONOS controlled LDP. SPIHS LDP 
Type 2 is a KSONOS/S2KHM Executive controlled LDP. The 
illustrations in this section do not specifically show these 
Executives; this is done for clarity. 

4.2 SPIHS LDP MODES 


Each LDP type provides two modes for terminal 
communications: 

♦ Normal Mode - display coded character strings, 
maximum of 150 characters per read, no limit on 
writes. 
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• Special Binary Bode (SBH) - ASCII coded character 
string, naxinua of '5000 characters per read or 
.write. 

Horaal Bode supports the transfer of display coded 
character strings, a aaxious of 150 characters per tersinal 
read. Terainal writes are buffered (as explained in section 
3. 3. 4.2), thus no output restrictions exist. All terainal 
control codes and network message enveloping is provided by 
TELEX-ICE. In addition. Normal Bode is used to communicate 
SBB request and status data. 

SBB supports the transfer of ASCII coded character 
strings {a maximum of 5000 characters per I/O request) . 

All code conversion is provided by the SPIMS Common 
Software package. All terminal control codes and network 
message enveloping is provided by the SPIMS Common Software. 
Figure 4-1 illustrates the format of an SBM File on mass 
storage. Figure 4-2 illustrates a possible format for an 
applications SBB data buffer, 

4.3 USER SIGN-ON 

Figure 4-3 illustrates the user/system interaction to 
establish a connection with TCS. Figure 4-4 illustrates a 
production application sign-on. Figure 4-5 illustrates a 
development application sign-on. 

All interaction between the user and the SPIBS is 
initially conducted in Normal Bode via an LDP Type 1. 
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TCS MESSAGE BLOCK 1 

9 ASCII Bytes HEADER 
351 ASCII Bytes Data* 
351 Characters maximum 

TCS MESSAGE BLOCK 2 

351 ASCII Bytes Data 
702 Characters maximum 

TCS MESSAGE BLOCK 3 

351 ASCII Bytes Data 
1053 Characters maximum 

TCS MESSAGE BLOCK 4 

351 ASCII Bytes Data 
1404 Characters maximum 

TCS MESSAGE BLOCK 5 

351 ASCII Bytes Data 
1755 Characters maximum 

TCS MESSAGE BLOCK 6 

351 ASCII Bytes Data 
2106 Characters maximum 

TCS MESSAGE BLOCK 7 

351 ASCII Bytes Data 
2457 Characters maximimi 

TCS MESSAGE BLOCK 8 

351 ASCII Bytes Data 
2808 Characters maximum 

TCS MESSAGE BLOCK 9 

351 ASCII Bytes Data 
3159 Characters maximum 

TCS MESSAGE BLOCK 10 

351 ASCII Bytes Data 
3510 Characters maximum 

TCS MESSAGE BLOCK 11 

351 ASCII Bytes Data 
3861 Characters maximum 

TCS MESSAGE BLOCK 12 

351 ASCII Bytes Data 
4212 Characters maximum 

TCS MESSAGE BLOCK 13 

351 ASCII Bytes Data 
4563 Characters maximum 

TCS MESSAGE BLOCK 14 

351 ASCII Bytes Data 
4914 Characters maximum 

TCS MESSAGE BLOCK 15 

351 ASCII Bytes Data 
5265 Characters maximum 


*These bytes are inverted 


64 

CENTRAL 

MEMORY 

WORDS 


Figure 4-2. — Format of special binary data buffer. 






*XXXX = TERMINAL USER ID 


Y = DEVICE TYPE 1 — H4000G SYNCHRONOUS 
DEVICE TYPE 2 - H4000G ASYCHRONOUS 
DEVICE TYPE 3 — H2000G ASYCHRONOUS 
DEVICE TYPE 4 - TTY COMPATIBLE ASYCHRONOUS 

Illegal user ID or teminal type causes 
ixon con f i rmat ion 


Figure 4-3, — Terminal-to-TCS access with $TON,XXX,Y command. 


4-5 







ESTABLISH 
TYPE 1 LDP 


AUTOMATED KROMOS 
USER IDENTIFICATION 


INITIALIZE 

APPLICATION 




USER NUMBER? 

(2) (PRESET USER NUMBER) 
© PASSWORD? 

(4) (PRESET PASSWORD) 



CALL "FILE NAME" 

FILE NAME IS A 
PROCEDURE PILE WHICH 
CONTAINS APPLICATION 
STARTUP PROTOCOLS. 


Figure 4-4, — Production application sign-on. 
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ESTABLISH 
TYPE 1 LDP 


request KRONOS 
USER IDENTIFICATION- 


♦ESTABLISH KRONOS 
COMMAND LANGUAGE 



♦FIVE RETRIES WITH INVALID USER HUMBER OR PASSWORD WILL TERMINATE THE LDP. 


Figure 4-5. — Development application sign-on. 
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4.4 ESTABLISH AN LDP TYPE 2 


A Type 2 LDP is estaBlished nithin the CYBER 74 using 
any of three nethods. 

• Control card - all directives are provided by the 
file input. 

• Control card file substitution - all directives are 
read froEB a predefined file. 

Figure 4-6 illustrates the control card methods. 

4.5 TERMINAL INPOT/ODTPUT NORMAL MODE 

Figures 4-7 through 4-10 illustrate the interfaces and 
data flow for terminal reads and writes. This terminal I/O 
has the following: 

• 150 character maximum input 

• Display coded data at the Application Level for all 
I/O, 

• Line/Line scrolling at the terminal. 

4,6 ESTABLISH TERMINAL I/O SPECIAL BINARY MODE 

Special Binary Mode files are created via standard CIO 
requests. The transfer of these file names to ICE is 
accomplished using a function code read/write sequence 
between the application and ICE. Figure 4-11 illustrates 
this sequence for LDP Type 1. Figure 4-12 illustrates this 
sequence for a Type 2 LDP. 
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SPIMS LOGICAL DATA PATH TYPE 2 


ESTABLISH 
TYPE 2 LDP 



Figure 4-6. — Control carcl initiated Type 2 LDP. 
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SPIMS LOGICAL DATA PATH TYPE 1 



Figure 4-7. — Application-to-terminal read (Normal Mode) 

for LDP Type 1. 
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Figure 4-8. — Application-to-temiinal write CNorraal Mode) 

for LDP Type 1. 
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SPIMS LOGICAL DATA PATH TYPE 2 



Figure 4-9. - Application-to-terminal read (Normal Mode) 

for LDP Type 2 , 
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SPIMS LOGICAL DATA PATH TYPE 2 



Figure 4-10. — Application- to- terminal write (Normal Mode) 

for LDP Type 2 . ’ 
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KRONOS REQUEST 


OPEN TWO MASS STORAGE FILES 


CIO 


APPLICATION 




WRITE 

REQUEST 


MESSAGE FORMAT 


FUNCTION CODE 0005 
SBM INPUT PILE NAME 
SBM OUTPUT FILE NAME 


MESSAGE FORMAT FUNCTION 


READ 

REQUEST 


FUNCTION CODE 0007 
STATUS* 


*0000 - SUCCESSFUL 

0001 - LOST DATA 

0002 - BAD DATA (HEADER) 

0003 - FNT ENTRIES NOT FOUND 

0004 - ALREADY INITIALIZED 
0020 - USER TERMINATED 


Figure 4-11, — Establish special binary mode files LDP type 1 
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MESSAGE FORMAT 



Figure 4-12. — Establish Special Binary Mode Piles LDP Type 2 




4.7 TERMIH&I. I/O SPECIAL BIMABY MODE 

Special Binary Mode (SBH) files are read or written via 
the SPIHS Comaon Software Library and the standard systea 
I/O requests for binary reads and writes. Special function 
codes have been established to determine the TELEX-ICE I/O 
processing required. These function codes are the first 12 
bits of a Normal Mode Nrite, The codes and services 
requested are: 

0005 - SBH files Initialization Request 

0006 - SBM Input Request 

0007 - SBM Output Request 

00021 - Application Termination Complete 
TELEX-ICE issues a return code and status for each request 
in the first 12 bits of data. This return code indicates 
the service requested and in the case of function code 0005 
the terminal type interacting with the application. The 
return codes are: 

4040 - Response to SBM Initialization Request (0005) 

4047 - Response to SBM Input Request (0006) 

4050 - Response to SBM Output Request (0007) 

The SBM status codes are; 

4040 - Successful Transmission 

4041 - Data Lost 

4042 - Bad Data (TCS header only) 

4043 - FNT Entries Not Found 

4044 - SBH Already Initialized 

4045 - Applications User Number Not Found 

4046 - Message Too Long 

4047 - Illegal Function 

4051 - Eerequest Previous Function 

4061 - User Signed OFF 
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The Noraal Bode path is used for these sequences. Figures 
4-13 through 4-16 illustrate the data interfaces and data 
flows for terainal tead/«rites. 
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SPIMS LOGICAL DATA PATH TYPE 2 



Figure 4-13. — Application-to-terminal write (Special 

Binary Mode) for LDP Type 2. 
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SPIMS LOGICAL DATA PATH TYPE 2 



Figure 4-14. — Application-to-terminal read (Special 

Binary Mode) for LDP Type 2. 
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SPIMS LOGICAL DATA PATH TYPE 1 



Figure 4-15. — Application-to-terminal read (Special 

Binary Mode) for LDP Type 1. 
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Figure 4-16. — Application-to— teinninal write (Special 

Binary Mode) for LDP Type 1. 
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4.8 USEE SIGN-OPF 


Figure 4-17 illus-trates a production application sign- 
off. Figure 4-18 illustrates a development application 
sign-off. Figure 4-19 illustrates the user commands/system 
interaction to disconnect from TCS. 


4-22 



SPIMS liOGJCAL DATA PATH TYPE 2 


REQUEST APPLICATION 

TERMINATION NOTIFICATION 



Figure 4-17. — Production application sign-off. 
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SPIMS LOGICAL DATA PATH TYPE 1 


TERMINATION 

REQUEST CONFIRMATION 

TERMINATION LDP CLEARED 



Figure 4”18. — Development application sign-off. 
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*XXXX - TERMINAL USER ID 


Figure 4-19. — Terminal- to-TCS disconnect with $TOP,XXXX command. 
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